-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
updated issue templates #463
Conversation
WalkthroughThe pull request includes updates to three issue templates in the Changes
Assessment against linked issues
Possibly related PRs
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (9)
.github/ISSUE_TEMPLATE/FEATURE.yml (2)
7-11
: Consider using a more generic placeholder example.While the current placeholder about traffic light detection is clear, it might be too specific for a general feature template. Consider using a more generic example that could apply to various types of features.
- placeholder: The vehicle should detect traffic lights and their states. + placeholder: Example: The system should implement user authentication with email verification.
17-20
: Revise Definition of Done examples to be more generic.The current examples are too specific to vehicle detection. Consider using more generic examples that would be applicable across different feature types.
placeholder: | - - Detects 90% of traffic lights. - - Correctly identifies 90% of traffic light states. + - Feature implementation is complete and tested + - Documentation is updated + - All acceptance criteria are met + - Code review is completed.github/ISSUE_TEMPLATE/ISSUE.yml (3)
10-15
: Consider enhancing the description prompts.While the current prompts are good, they could be more comprehensive to gather additional context.
placeholder: | Enter description here: - What is the problem? - What is the expected outcome? + - What is the impact of this issue? + - Any relevant context or background?
31-33
: Add format guidance for effort estimates.The effort estimate field would benefit from a clear format specification.
label: Effort Estimate description: Estimate the effort required. - placeholder: Enter effort estimate here. + placeholder: Enter estimate in days or hours (e.g., "2d" or "4h")
38-40
: Consider adding example test criteria.The testability section is well-structured, but could be more helpful with examples.
label: Testability description: How to verify the issue's resolution. - placeholder: Enter test methods and validation criteria. + placeholder: | + Enter test methods and validation criteria: + - Unit test scenarios + - Integration test requirements + - Manual verification steps.github/ISSUE_TEMPLATE/BUG.yml (4)
3-3
: Consider enhancing the description for better clarity.The description could be more specific to help users understand when to use this template.
-description: A bug that requires attention. +description: Report unexpected behavior or issues that need to be fixed.
10-11
: Consider using more generic examples in placeholders.The current examples are specific to autonomous vehicles. Consider using more generic examples to make the template more universally applicable across different types of bugs.
- placeholder: The car doesn't detect the traffic light on Map1. + placeholder: The search function returns incorrect results for specific queries. - placeholder: The car should detect the traffic light on Map1. + placeholder: The search function should return accurate results for all valid queries. - * Start simulation on Map1. - * After 600m, the car should stop at the traffic light. + * Enter a search query with special characters + * Click the search button + * Observe the resultsAlso applies to: 17-18, 26-27
29-58
: Well-structured new fields that align with requirements.The new fields effectively address the requirements from issue #372. The structure is consistent and logical.
Consider enhancing the placeholders with more detailed examples:
- placeholder: Enter effort estimate. + placeholder: "e.g., 4h, 2d (h=hours, d=days)" - placeholder: Describe testing steps for verification. + placeholder: | + * Unit test cases needed + * Integration test scenarios + * Manual verification steps - placeholder: Link dependencies here (e.g., #123). + placeholder: | + * Blocked by: #123 + * Related to: #456 + * Required for: #789
59-73
: Well-structured label guidance section.The priority and group labels are clearly defined and provide good guidance for issue categorization.
Consider adding a brief note about label requirements:
**Add Priority Label**: + Please select exactly one priority label: - p1: Immediate attention ... **Add Group Label**: + Please select at least one group label: - perception: Related to sensor processing and scene understanding ...
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
.github/ISSUE_TEMPLATE/BUG.yml
(1 hunks).github/ISSUE_TEMPLATE/FEATURE.yml
(1 hunks).github/ISSUE_TEMPLATE/ISSUE.yml
(2 hunks)
🔇 Additional comments (7)
.github/ISSUE_TEMPLATE/FEATURE.yml (3)
3-3
: LGTM! Clear and concise template description.
The description accurately reflects the template's purpose.
22-41
: LGTM! Well-structured new sections.
The new sections for Effort Estimate, Testability, and Dependencies are well-designed and directly address the requirements from issue #372. They will help in better project planning and quality assurance.
43-57
: Consider making group labels configurable.
While the priority labels are well-defined and universal, the group labels are very specific to autonomous vehicle systems. Consider either:
- Moving these labels to a configuration file for better maintainability
- Making them more generic for broader project types
Let's check if other templates use similar labels:
.github/ISSUE_TEMPLATE/ISSUE.yml (4)
1-4
: LGTM! Clear and consistent metadata structure.
The template metadata is well-organized with appropriate naming and labeling conventions.
20-26
: LGTM! Well-structured Definition of Done criteria.
This addition successfully addresses the requirement from issue #372 for including a Definition of Done section.
45-47
: LGTM! Clear dependency linking guidance.
The section provides clear instructions with helpful example format.
Line range hint 52-73
: Verify label consistency with repository.
The label structure is clear and comprehensive. However, we should verify that all listed labels exist in the repository.
✅ Verification successful
All labels in the template exist in the repository
The verification confirms that all labels mentioned in the template exist in the repository:
Standard Labels:
- ✓ bug
- ✓ enhancement
- ✓ help wanted
- ✓ discussion
- ✓ documentation
- ✓ question
- ✓ wontfix
Priority Labels:
- ✓ p1
- ✓ p2
- ✓ p3
- ✓ p4
Group Labels:
- ✓ perception
- ✓ planning
- ✓ acting
- ✓ research
- ✓ infrastructure
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all labels mentioned in the template exist in the repository
# Extract labels from the template
echo "Labels defined in template:"
rg -A 20 "Add Standard Label" .github/ISSUE_TEMPLATE/ISSUE.yml
# Get actual repository labels using GitHub CLI
echo -e "\nActual repository labels:"
gh label list
Length of output: 2001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks more professional and specific, but I have some minor changes suggested.
Co-authored-by: asamluka <[email protected]>
Co-authored-by: asamluka <[email protected]>
Co-authored-by: asamluka <[email protected]>
Co-authored-by: asamluka <[email protected]>
Co-authored-by: asamluka <[email protected]>
Co-authored-by: asamluka <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accepted all requested changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
.github/ISSUE_TEMPLATE/FEATURE.yml (1)
14-21
: Consider expanding the Definition of Done criteria.The current criteria are specific and measurable, which is excellent. Consider adding criteria about documentation and testing requirements.
placeholder: | - Detects 90% of traffic lights. - Correctly identifies 90% of traffic light states. + - Documentation updated with new feature details + - Unit tests implemented with >80% coverage.github/ISSUE_TEMPLATE/BUG.yml (3)
3-3
: Consider a more descriptive template description.The current description "A bug that requires attention" is quite generic. Consider something more specific like "Report unexpected behavior or functionality that isn't working as designed."
-description: A bug that requires attention. +description: Report unexpected behavior or functionality that isn't working as designed.
10-11
: Consider using more generic examples in placeholders.The current examples are specific to autonomous vehicles. Consider using more generic examples that would apply to any software project.
- description: Describe the current, unexpected behavior. - placeholder: The car doesn't detect the traffic light on Map1. + description: Describe what is currently happening that shouldn't be. + placeholder: The application crashes when processing files larger than 1GB. - description: Describe the expected, correct behavior. - placeholder: The car should detect the traffic light on Map1. + description: Describe what should happen instead. + placeholder: The application should handle large files without crashing.Also applies to: 17-18
23-28
: LGTM on the section rename, but consider generic examples.The rename to "Steps to Reproduce" is a good improvement. However, like the previous sections, consider using more generic example steps.
placeholder: | - * Start simulation on Map1. - * After 600m, the car should stop at the traffic light. + 1. Open the application + 2. Upload a file larger than 1GB + 3. Click the process button
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
.github/ISSUE_TEMPLATE/BUG.yml
(1 hunks).github/ISSUE_TEMPLATE/FEATURE.yml
(1 hunks).github/ISSUE_TEMPLATE/ISSUE.yml
(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/ISSUE_TEMPLATE/ISSUE.yml
🔇 Additional comments (7)
.github/ISSUE_TEMPLATE/FEATURE.yml (5)
1-5
: LGTM! Clear and well-structured header section.
The template header provides clear identification and proper labeling.
7-11
: LGTM! Clear description field with good example.
The description field is well-structured with a relevant placeholder example.
22-28
: Update effort estimate field to match agreed format.
A previous review suggested a specific format for this field.
label: Effort Estimate
- description: Approximate effort required (e.g., hours).
- placeholder: Enter effort estimate.
+ description: Approximate effort required (e.g., hours)
+ placeholder: Enter effort estimate
29-41
: LGTM! Well-structured new fields.
The testability and dependencies fields provide clear guidance and appropriate placeholders.
43-58
: LGTM! Comprehensive label guidance.
The priority and group labels are well-defined and provide clear categorization options.
.github/ISSUE_TEMPLATE/BUG.yml (2)
29-58
: Excellent addition of structured fields!
The new sections (Definition of Done, Effort Estimate, Testability, and Dependencies) are well-structured and address the objectives outlined in issue #372. These additions will significantly improve issue tracking and resolution workflow.
59-74
: Well-structured label system with comprehensive coverage.
The priority and group labels are clearly defined and provide good categorization. The suggestion from the previous review about system engineering has been appropriately incorporated as the "system" label.
Description
This extends the issue templates to have a uniform and complete template for all issue types. When merged it should be checked whether the changes worked as intended.
Fixes #372
Type of change
Please delete options that are not relevant.
Does this PR introduce a breaking change?
No
Most important changes
Check if the templates are missing any, in your opinion important input fields
Checklist:
Summary by CodeRabbit
New Features
Definition of Done
,Effort Estimate
,Testability
, andDependencies
to both templates.Bug Fixes
Documentation